Technical Field
Aspects of the embodiments relate to integrated network systems that include use of two or more Ethernet devices.
Background Art
It is a fundamental limitation of Ethernet networks that they not contain switching loops. FIG. 1 illustrates Ethernet network 100 in which a cycle can occur. In one series of applications, such Ethernet networks can be used in products manufactured by Crestron Electronics Inc. (from hereon in “Crestron”), and can include Digital Media (DM) products. From time-to-time within this discussion, reference will be made to certain one or more of products, systems, and protocols manufactured/designed/used by Crestron that include problems described in the Background Art section and further incorporate the aspects of the embodiments described below that solve those problems.
In FIG. 1, Ethernet network 100 includes main central processor unit (CPU) 102, CPU input/output (IO) 104, communication paths 106a-n, “Blades” (or 1:n multiplexors) 114(1)-(16), and a plurality of end points (EP) 112. Ethernet network 100 is also tied into another larger Ethernet network 120 via communication paths 106a-n. EP 112 can be any source or sink of video/audio/data. As those of skill in the art can appreciate, Ethernet applies to data-only communications, such data including system configuration data, by way of non-limiting example only. In particular, the data that is being communicated can include a product such as Cresnet connectivity, universal serial bus (USB) forwarding, and other product-internal communications. For example, in Crestron's DM products, video and audio are transmitted via time divisional multiplexing signal transmission (TDMS) scheme, not Ethernet. Nonetheless, Ethernet is used in video/audio switching operations in not only Crestron products, but other systems that transmit data, video, and audio signals as well. Typically, as shown in FIG. 1, each Blade 114 has 8 EPs 112, and there are typically up to 16 blades for each main CPU 102.
A switching loop is a transmission-retransmission that occurs repeatedly and rapidly, and often leads to what is then referred to as a packet storm. A switching loop exists whenever there is more than one active path between two endpoints in the network. The uncontrolled retransmission is the packet storm. Packet storms typically occur between devices that act as bridges. As those of skill in the art can appreciate, a bridge in an Ethernet network is a device that monitors and keeps track of other devices, such as EPs 112 that are connected to the bridge; that is, it knows, or creates a table, of the devices on its input and output so that it can correctly route Ethernet packets to the correct location. If a packet were to be received by a bridge, and it did not correspond to any device “downstream” the bridge would forward the packet to all ports other than the port on which the packet was received. However, each time the bridge receives a packet, the source address is added to the switching table for the port it was received on so that future packets destined for that address may be efficiently switched to the correct port only this promotes the efficient use of the network according to known Ethernet protocols. The repeated cycling transmission-retransmission of a message between a first device, for example CPU 102, and switch 108 (as shown as circular arrow line A), can create a packet storm. Such an event is called a packet storm because Ethernet transmits data/information on a packet basis (meaning the data in encapsulated within a packet on a packet-based network).
As those of skill in the art can appreciate, introduction of a cycle into Ethernet network 100 will cause a packet storm and system failure. Such events can cause significant amounts of lost time, and consequently, in a corporate/business environment, lost productivity.
A common solution is to use Rapid Spanning Tree Protocol (RSTP). RSTP runs on each bridge and manages the state of ports based on link status and RSTP-specific packets called Bridge Protocol Units (BPDUs) that are exchanged between bridges. The copy of the RSTP on the bridge is known as an “instance.” A network bridge is a network device that connects multiple network segments. For example CPU 102 can be designated a network bridge, even though it may perform other functions as well. Upon any change in the physical network topology (i.e., connecting or disconnecting a new component, such as an EP 112, or blade 114), the RSTP instance on each bridge enables and disables ports so as to build a tree which spans the network. A tree contains no cycles by definition, and so the Ethernet packet storm is avoided. This approach, however, is suitable for bridges that contain a single CPU and a single Ethernet switch. However, a problem arises when multiple CPUs and Ethernet switches are employed within the same product.
In FIG. 2, root node 202 (which can also be the main CPU), is connected to a plurality of bridges 204a-e via links 206a-f. An instance of RSTP is installed in root node 202. The resulting enabled and disabled links 206a-f will be chosen so as to minimize the total path cost from any node 204 to root node 202. The result is shown in FIG. 3. RSTP will then disable link 206c (indicated by broken line), so as to minimize the total path cost from any node to the root. Note that link 206d could also have been disabled, and the result would have been the same.
Nonetheless, while solving the problem of cycles, problems can arise from the application of RSTP in complex products. For example, in the configuration of FIG. 4, wherein node 204c is replaced by another CPU, i.e., a second “root node” 202b, and the six devices are split up as shown (i.e., first sub-network 402a and second sub-network 402b), with in-blades (204d, 204a) and out-blades (204e, 204b). Then, any communication from second root node 202b to node 204b needs to go from second sub-network 402b via node 204d, to first sub-network 402a and node 204e, then through first root node 202a, node 204a and then out of first sub-network 402a back to second sub-network 402b and node 204b, as indicated by arrow A. This is problematic because it will introduce unacceptable delays in communications between non-root main CPU 202b and out-blade/node 204b, as these communications will have to circumnavigate the entire network.
Furthermore, as those of skill in the art can appreciate, each CPU-Ethernet switch pair can be treated as a bridge, and therefore run as many instances of RSTP as there are CPUs in the system. The problem is that when multiple switches with this implementation are attached together, all but one of the switches configures itself in a state where Ethernet links within the system's Ethernet backbone are disabled and traffic within the system is forced to travel through peer systems, as shown in FIG. 4.
In addition, as those of skill in the art can appreciate, each link in an Ethernet network can be assigned a cost. The cost is proportional to the latency (high latency, high cost), and therefore inversely proportional to the bandwidth (low bandwidth, high cost). If a true minimum spanning tree were computed based on these link costs, then the problem could be solved by assigning a low cost to product-internal links. However, RSTP does not compute a true minimum spanning tree but rather computes the tree wherein each node has the minimum cost to an elected network root node. This is acceptable in fully hierarchical networks but breaks down for more complex scenarios which involve the use of multi-centered networks. In a multi-centered network topology (e.g., more main central processing units 102), link cost adjustment is not sufficient to prevent RSTP from breaking internal links.
Still further, stability is inversely related to bridge count. This means that after link state change, the time to convergence on a spanning tree increases, resulting in periods of either lost Ethernet connectivity or packet storms before the network stabilizes.
One potential solution to the problem with RSTP is to connect the Ethernet switches together using a technique called “trunking,” under which the switches act as a single switch at the hardware level. The connection between the switches is then called a “network fabric.” This solution has a severe limitation however: All Ethernet switches employed must have compatible trunking technology. Practically, this means using switches from the same product line and from the same manufacturer. This restriction is technically difficult to work with and is untenable in the long run for products that include lots of Ethernet devices, some of which might be located in different locations. As those of skill in the art can appreciate, the flexibility of using heterogeneous Ethernet switches is highly desired (because it allows for flexibility and cost efficiency). Consequently, the latencies and uncertainties introduced by the RSTP problem described above has made Ethernet connectivity to peer switches untenable for media switchers relying on Ethernet for inter-board communications, pending a solution.
Thus, there is a need for improving the use of Ethernet networks in order to provide reliable network connectivity.